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If this communication is filed after the shortened statutory time period 
had elapsed and no separate Petition is enclosed, the Commissioner of Patents and 
Trademarks is petitioned, under 37 CFR 1.136(a), to extend the time for filing a 
response to the outstanding Office Action by the number of months which will 
avoid abandonment under 37 CFR 1.135. The fee under 37 CFR 1.17 should be 
charged to our Deposit Account No. 50-2215. 

This brief is transmitted in triplicate. 

This brief contains items under the following headings as required by 37 
C.F.R. § 1.192 and M.P.E.P. § 1206: 

L Real Party In Interest 

II Related Appeals and Interferences 

III. Status of Claims 

IV. Status of Amendments 

V. Summary of Invention 

VI. Issues 

VTI. Grouping of Claims 

VIII. Arguments 

IX. Claims Involved in the Appeal 
Appendix A Claims 

I. REAL PARTY IN INTEREST 

The real party in interest for this appeal is: 

JPMorgan Chase Bank 
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II. RELATED APPEALS AND INTERFERENCES 

There are no other appeals or interferences which will directly affect or be 
directly affected by or have a bearing on the Board's decision in this appeal. 

III. STATUS OF CLAIMS 

A. Total Number of Claims in Application 
There are 131 claims pending in application. 

B. Current Status of Claims 

1. Claims canceled: None 

2. Claims withdrawn from consideration but not canceled: 113- 
115, 118-135 

3. Claims pending: 1-112, 116-117, 136-152 

4. Claims allowed: None 

5. Claims rejected: 1-112, 116-117, 136-152 

C. Claims On Appeal 

The claims on appeal are claims 1-112, 116-117, 136-152 

IV. STATUS OF AMENDMENTS 

Applicant filed a Response After Final Rejection on July 19, 2004. The 
Examiner responded to the Response After Final Rejection in an Advisory Action 
mailed August 3, 2004. In the Advisory Action, the Examiner indicated that 
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Applicants' proposed amendments to the claims would not be entered. However, 
there were no amendments to the claims. Further, the Examiner stated that the 
request for consideration does not place the application in condition for allowance. 
The only amendments made to the claims were those made in a preliminary 
amendment filed April 18, 2001. 

Accordingly, the claims enclosed herein as Appendix A incorporate the 
amendments indicated in the paper filed by Applicant on April 18, 2001. 

V. SUMMARY OF INVENTION 

The present invention relates to a computerized workflow management 
method and system to provide operational support for complex multi-step processes, 
having particular utility in supporting operations involving securitizations for which 
periodic valuation and distribution computations, disbursements and reporting must 
be set up and executed. See, Abstract. 

The method involves creating an underlying database structure for 
recording the processing steps and other information required for each deal, 
entering the necessary setup information by selection from lists of pre-stored 
information about processing functions, the associated workflow events (referred to 
herein as "queues") and status milestones for the queues, mapping the data 
structures of the subsystem databases and the workflow management database to 
provide transparent interfacing and convenient manual entry of data were necessary, 
displaying for the user the queue and milestones status of all the deals for which he 
or she is responsible, permitting menu driven initiation of the tasks required in each 
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queue each the deals and automatically updating the database records for the 
universe of deals being managed by the system. See, page 6. 

Generally, a user performs a task by selecting the task name from an 
Actions List on an Active Deals Screen. For some actions, e.g., approval, nothing 
further is required; the workflow management software updates the status records 
for the deal in Workflow Database 244, moves the deal to the next queue and/or 
milestone, and updates the listing for the deal on the user's Active Deals Screen. 
For tasks requiring data input, selecting the task brings up a data entry screen. For 
tasks involving review and/or editing of data, the reviewer can bring up the 
appropriate screen to ensure that all data are correct and process the approval or the 
editor can bring up the appropriate screen in order to edit the data. For yet other 
actions, e.g., Deny, Un-Approve (withdraw an approval) or Restate (i.e. to correct 
errors after a payment has been made), supporting comments are required. In those 
instances, after the task is selected, a comment entry screen appears. See, page 17. 

The invention provides an effective solution to workflow management for 
complex financial transactions involving many deals and data which changes on a 
frequent basis. It also permits modification of the data structures as needed to 
accommodate evolutionary changes in the financial structures of the deals being 
handled. In the preferred embodiment, the invention is implemented using a 
relational database management system on a computer network organized on a 
client-server model. See, page 64. 
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VI. ISSUES 

Are the Group I claims patentable over State Street (1997) in view of 
Poindexter (U.S. Patent No. 6,338,074) and further in view of Notani (U.S. Patent 
No. 6,442,528)? 

VIL GROUPING OF CLAIMS 

For purposes of this appeal brief only, and without conceding the 
teachings of any prior art reference, the claims have been grouped as indicated 
below: 

Group Claim (s) 

I. 1-112, 116-117, 136-152 

II. 113-115, 118-135 (are withdrawn from consideration). 

In Section VIII below, Applicant has included arguments supporting the 
patentability of the group I claims as required by M.P.E.P. § 1206. 

The Group I claims stand or fall together. 

VIII. ARGUMENTS 

A. Are the Group I claims patentable over State Street 1 in view of 

Poindexter (U.S. Patent No. 6,338,074) and further in view of Notani 
(U.S. Patent No. 6,442,528)? 

In the Final Office Action dated February 18, 2004, the Examiner issued a 
final rejection for each of the pending claims. The pending claims were rejected 



1 A copy of State Street is attached hereto as Appendix B. 
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under 35 U.S.C. § 103 (a) as being obvious in light of State Street in view of 
Poindexter and further in view of Notani. 

B. OBVIOUSNESS 

Paragraph 5 of the Final Office Action rejects the group I claims 2 and 4 
as being obvious over State Street in view of Poindexter and further in view of 
Notani. It is axiomatic that in order to establish a prima, facie case of obviousness, 
the Office Action must show that the combination of prior art references discloses 
each and every element of the group I claims. In the present case, the Examiner has 
failed to establish a prima facie case of obviousness. 

To establish a prima facie case of obviousness, there must be some 
suggestion or motivation, either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art, to modify a reference or 
combine references to arrive at the claimed subject matter. The prior art references 
must also teach or suggest all the limitations of the claim in question. See, M.P.E.P. 
§ 706.02(j) (emphasis added). A reference can only be used for what it clearly 
discloses or suggests. See, In re Hummer , 113 U.S.P.Q. 66 (C.C.P.A. 1957); In re 
Stencel, 4 U.S.P.Q.2d 1071, 1073 (Fed. Cir. 1987). Here, the prior art references, 
whether taken individually or in combination, do not disclose or suggest the 
invention claimed by the Applicant. 

To be a prior art reference, the reference must be a printed publication 
and accessible to the public before the filing date of the application. In re Hall , 228 
U.S.P.Q. 453 (Fed. Cir. 1986); M.P.E.P. § 2128. M.P.E.P. § 2128.01. A 
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publication that does not include a publication date (or a retrieval date) cannot be 
relied upon as prior art under 35 U.S.C. § 102(a) or (b) although it may be used to 
show the state of the art at or around the time the invention was made . See, 
M.P.E.P. §§ 2124, 2128 (emphasis added). In the present case there has been no 
showing that the undated State Street reference was accessible to the public prior to 
the filing date of the present application or that it shows the state of the art at or 
around the time the invention was made. 

Applicants submit that the Examiner has not properly established the State 
Street document as prior art. The Examiner has taken the position that the State 
Street web pages can be dated using a completely unrelated FDIC Letter, dated 
December 13, 1999. Applicant's strongly disagree with this position. The cited 
State Street documents themselves have no publication date and do not refer to the 
FDIC letter. Likewise, the FDIC letter does not reference the State Street 
reference. The FDIC Letter cannot be relied upon to date the web pages or the 
disclosure therein because it does not refer to the State Street system. See, In re 
Epstein , 31 U.S.P.Q.2d 1817 (Fed. Cir. 1994) (Abstracts, which are not prior art 
under section 102(b), that refer to a "release" or "first installation" date for its 
respective software product of more than one year before appellant filed his patent 
application can be used to show (1) that the software products described in the 
abstracts were "in public use or on sale" within the meaning of section 102(b) and 
thus properly considered prior art, and (2) the level of skill in the art at the time the 
invention was made). 
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The Examiner incorrectly asserts that the publication date of the State 
Street material is the date that the FDIC released a letter for guidance on Asset 
Securitization. The FDIC Letter merely establishes that, at least by December 13, 
1999, the FDIC had provided guidance regarding asset securitization. The 
Examiner has used this date in combination with the self-serving statement from the 
State Street Web site that u [s]ince inception of the U.S. securitization market, we 
have shown a commitment to the market by successfully serving as administrator, 
credit enhancer, placement agent, investor and trustee" to date the Web page as of 
December 13, 1999. State Street's quote from the website merely states that they 
have been involved in the securitization market since its inception. It states nothing 
about which of its processes were practiced or when they were practiced. 

Applicants admit that the practice of asset securitization has existed in the 
United States since the early 1970s. Using the logic in the Office Action, the State 
Street web pages should therefore be considered prior art as of the 1970s. Clearly, 
this is absurd. The fact that State Street claims they have been involved in asset 
securitization since the 1970s does not establish that State Street's web pages were 
published in the 1970s. Furthermore, merely being involved in asset securitization 
activities does not in any way establish State Street had a computerized method for 
work flow management for a trustee handling a plurality of securitization 
transactions or that such a system was discussed on the State Street Web site. 

The Office Action has provided no reasonable evidence whatsoever that 
the State Street reference was actually available as of the filing of the present 
Application as specifically required by the M.P.E.P. Further, there has been no 
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showing that the State Street reference discloses the state of the art at the time of 
the invention. As such, Applicants assert that the State Street reference is not prior 
art and therefore may not be used as a reference. 

As the State Street is not a prior art reference as against the present 
application, withdrawal of the rejections based on State Street is respectfully 
requested. 

The remaining references, Poindexter and Notani, fail to disclose all of the 
limitations in Applicants' pending claims. Poindexter and Notani were not cited to 
disclose a computerized method for workflow management for a trustee handling a 
plurality of securitization transactions but for other deficiencies noted by the 
Examiner in State Street reference. Whether or not Poindexter and Notani disclose 
the limitations for which they are cited is irrelevant as the Examiner has failed to cite 
a valid reference disclosing a computerized method for workflow management for a 
trustee handling a plurality of securitization transactions. As such, Applicants 
respectfully request withdrawal of the pending rejection. 
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CLAIMS INVOLVED IN THE APPEAL 

A copy of the claims involved in the present appeal is attached hereto as 
Appendix A. As indicated above, the claims in Appendix A include the amendments 
filed by Applicant on April 18, 2001. 

Dated: November 4, 2004 



DICKSTEIN SHAPIRO MORIN & 

OSHINSKY LLP 
1177 Avenue of the Americas 
New York, New York 10036-2714 
(212) 835-1400 
Attorney for Applicant 

IRB/mgs 
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APPENDIX A 

Claims Involved in the Appeal of Application Serial No. 09/631,810 

1. A computerized method of workflow management for a trustee 
handling a plurality of securitization transactions comprising the steps of: 

recording deal setup information in an electronic database including 
information related to the structure of each of the securitizations; 

recording workflow status information for each of the securitizations in 
the electronic database; 

periodically receiving asset level data transmitted by at least one asset 

manager; 

aggregating the asset level data; 

transmitting the aggregated asset level data electronically to a workflow 
management software module; 

providing an active deals display generated by the workflow 
management software module, based at least in part on the recorded deal setup 
information and the recorded workflow status information, which display provides 
access to workflow status information for particular securitizations, provides prompts 
for a user as to work which is to be done with respect thereto, and permits the user 
to initiate actions required for performance of the trustee's duties; and 

updating the recorded workflow status information for the 
securitizations based on work performed with respect thereto. 

2. The method described in claim 1, wherein the steps are performed 
under control of the workflow management software module. 
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3. The method described in claim 1 further including the step of 
electronically transmitting data concerning payments due investors in the 
securitization from the workflow management software module to a software 
module which processes payments to the investors based on the transmitted data. 

4. The method described in claim 3, further including the step of 
electronically disseminating reports and other data compilations upon completion of 
the payment processing. 

5. The method described in claim 1 further including the step of 
calculating waterfall payments due investors in the securitizations on a periodic basis 
in accordance with the deal structure and the aggregated asset level data; 

6. The method described in claim 5, further including the step of 
performing calculations of taxes owed by the investors on the waterfall payments 
based on the waterfall calculations. 

7. The method described in claim 1, in which the step of aggregating the 
asset level data is performed by a first software module separate from the workflow 
management software module. 

8. The method described in claim 7, further including the step of 
providing an interface which maps the data produced by the first software module 
for compatibility with the workflow management software module. 

9. The method described in claim 1, in which the workflow status 
information is displayed in terms of basic functions associated with management of 
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the securitization, workflow events associated with the basic functions and 
milestones associated with the workflow events. 

10. The method described in claim 9, in which the basic functions include 
waterfall processing and tax processing. 

11. The method described in claim 10, in which the workflow events 
associated with the waterfall processing function include a Data Aggregation queue, 
a Data Preparation queue, a Ready for Waterfall Processing queue, a Waterfall 
Approval queue and a Payment queue. 

12. The method described in claim 11, in which the milestones associated 
with the Data Aggregation queue include Not Ready, Data Received and Denied. 

13. The method described in claim 12, further including the step of 
changing the workflow status of a securitization in waterfall processing to the Data 
Aggregation queue and Not Ready status when a previous payment cycle has been 
completed. 

14. The method described in claim 13, further including the step of 
changing the workflow status of a securitization in the Data Aggregation queue and 
the Not Ready milestone to Data Received status when asset level data for a new 
waterfall processing cycle is received. 

15. The method described in claim 14, further including the step of 
changing the workflow status of a securitization from Not Ready to Data Received 
status in response to a user command. 
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16. The method described in claim 12, further including the step of 
changing the workflow status of a securitization in the Data Received milestone to 
the Data Preparation Queue and the Tape Run milestone if the aggregated asset 
level data is ready for further processing, or is transferred to Data Denied status in 
the Data Aggregation queue if the aggregated asset level data is incomplete, 
inaccurate or otherwise not ready for further processing. 

17. The method described in claim 16, further including the steps of: 
permitting a user to review the aggregated data and to approve or 

reject the data, and 

changing the workflow status of the securitization to the Data 
Preparation queue and the Tape Run milestone if the user approves the data, or to 
the Data Denied status in the Data Aggregation queue if the user rejects the data. 

18. The method described in claim 17, further including the step of 
requiring entry of supporting comments by the user into a data entry screen before 
changing the status to Data Denied if the user has rejected the data. 

19. The method described in claim 16, further including returning the 
workflow status of a securitization in the Data Denied milestone to Data Received 
status when new or corrected aggregated data is received. 

20. The method described in claim 11, in which the milestones associated 
with the Data Preparation queue include Not Ready, Tape Run, Loan Level 
Processed and Denied. 
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21. The method described in claim 20, wherein, for a securitization in the 
Data Preparation queue and the Not Ready milestone, the actions which the user is 
permitted to initiate include: 

an Approve action; and 
a Data Entry action. 

22. The method described in claim 21, further including the step of: 
changing the workflow status to the Ready for Waterfall Processing 

queue and the Ready milestone in response to an Approve action. 

23. The method described in claim 21, further including the step of: 
making a data entry screen available to the user when a Data Entry 

action is initiated. 

24. The method described in claim 20, further including the step of 
changing the workflow status of a securitization in the Data Preparation queue and 
the Tape Run milestone to the Asset Level Processed status in the Data Preparation 
queue by the workflow management software module when the data aggregation 
operation has been completed, or to the Data Aggregation queue and Data Denied 
status in response to a user command. 

25. The method described in claim 24, further including the steps, for a 
securitization in the Data Preparation queue and the Asset Level Processed 
milestone, of: 

permitting the user to review the aggregated asset level data, and to 
accept or reject the data according to predefined criteria; and 
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changing the workflow status of the securitization to the Ready For 
Waterfall Processing queue and the Ready status if the user approves the data, or to 
the Data Denied status in the Data Prep queue if the data is rejected. 

26. The method described in claim 20, wherein, for a securitization in the 
Data Preparation queue and the Denied milestone, the actions which the user is 
permitted to initiate include: 

a Deny to Asset Level Aggregation action; 
an Enter Data action; and 
an Aggregate action. 

27. The method described in claim 26, further including the step of 
changing the workflow status to the Asset Level Aggregation queue and the Denied 
status when the Deny to Asset Level Aggregation action is taken. 

28. The method described in claim 26, further including the step of 
making a data entry screen available to the user when the Enter Data action is 
initiated. 

29. The method described in claim 26, further including the steps of: 
performing an asset level data aggregation when the Aggregate action 

is initiated; and 

changing the workflow status to Loan Level Processed in the Data 
Preparation queue when the asset level data aggregation has been completed. 

30. The method described in claim 11, in which the milestones associated 
with the Ready for Waterfall Processing queue include Ready and Denied. 
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31. The method described in claim 30, wherein, for a securitization in the 
Ready for Waterfall Processing queue and Ready status, the actions which a user is 
permitted to initiate include: 

a Deny action; 

a Run Waterfall action; 

an Enter Data action; 

an Add Special Headers/Footers action; and 
an Add Asset Level Information action. 

32. The method described in claim 31, further including the step of 
returning the workflow status of the securitization to the Data Ready Queue and 
Data Denied milestone when a Deny action is selected. 

33. The method described in claim 31, when the Run Waterfall action is 
selected, further including the steps of: 

providing the asset level data to a third software module for waterfall 
processing; and 

when the waterfall processing has been completed, changing the 
workflow status to the Waterfall Approval queue and Ready milestone. 

34. The method described in claim 31, when the Enter Data, the Add 
Special Headers/Footers or the Add Asset Level Information actions are selected, 
further including the steps of: 

making data entry screens accessible to the user; and 
after data entry has been completed, returning the user to the list of 
permitted actions. 
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35. The method described in claim 30, wherein, for a securitization in the 
Ready for Waterfall Processing queue and Denied status, the actions which a user is 
permitted to initiate include: 

a Deny action; and 
a Run Waterfall action. 

36. The method described in claim 35, further including the step of: 
changing the workflow status to the Data Ready queue and Data 

Denied status when a Deny action is initiated. 

37. The method described in claim 35, when a Run Waterfall action is 
initiated, further including the steps of: 

providing the asset level data to a third software module for waterfall 
processing; and 

thereafter, when the waterfall processing is completed, changing the 
workflow status to the Waterfall Approval queue and Ready status. 

38. The method described in claim 11, in which at least a Ready milestone 
is associated with the Waterfall Approval queue. 

39. The method described in claim 38, wherein, for a securitization in the 
Waterfall Approval queue, further including the steps of: 

performing at least one predefined test under control of the user to 

verify the accuracy of the waterfall calculations; 

permitting the user to approve the data if the test is passed; and 

in response to approval of the data by the user, changing the workflow 

status to the Payment queue and Final Approval status. 
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40. The method described in claim 39, further including the steps of: 
permitting the user to select the Deny action if the verification test is 

not passed; and 

in response to selection of the Deny action, changing the workflow 
status to a predetermined status level in an earlier queue. 

41. The method described in claim 38, wherein, for a securitization in the 
Waterfall Approval queue, further including the steps of: 

performing a series of predefined tests to verify the accuracy of the 
waterfall calculations; and 

if the tests are passed, changing the workflow status to the Payment 
queue and Final Approval status; or 

if the tests are not passed, changing the workflow status to a 
predetermined queue and milestone as a function of which of the tests in the series 
was not passed. 

42. The method described in claim 11, in which the milestones associated 
with the Payment queue include Final Approval, Received by Payment System, and 
Payment Made. 

43. The method described in claim 42, for a securitization in the Payment 
queue and Final Approval status, further including the steps of: 

changing the workflow status to the Received by Payment Systems 
milestone; and 

providing the waterfall data to a payment processing software module 
for payment processing. 
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44. The method described in claim 42, for a securitization in the Payment 
queue and the Received by Payment Systems milestone, further including the step 
of: 

when the payment processing is complete, changing the workflow 
status to the Payment Made milestone. 

45. The method described in claim 42, for a securitization in the Payment 
queue and the Payment Made milestone, further including the steps of: 

selecting the next waterfall distribution date; and 

the workflow status to the Data Aggregation queue and the Not Ready 

milestone. 

46. The method described in claim 10, in which the workflow events 
associated with the tax processing function include a Ready for Tax Processing 
queue, a Tax Approvals queue and a Tax Reports queue. 

47. The method described in claim 46, wherein, for a securitization in tax 
processing, in the Ready for Tax Processing queue, the actions which the user is 
permitted to initiate irrespective of the milestone, include: 

an Enter Data action; and 
a Run Tax Processing action. 

48. The method described in claim 47, further including the step of 
making a tax data entry screen accessible to the user if the Enter Data action is 
selected. 

49. The method described in claim 47, further including the steps of: 
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making the waterfall data available to a tax processing software module 
for computation of taxes due on the waterfall payments; and 

after the tax computations have been completed, changing the 
workflow status to the Tax Approval queue and Ready status. 

50. The method described in claim 49, further including the step of 
performing tax computations for each of the waterfall payment periods. 

51. The method described in claim 46, wherein, for a securitization in the 
Tax Approval queue, and the Ready milestone, the actions which the user is 
permitted to initiate include: 

an Approval-Monthly action; and 
an Approval-Annual action. 

52. The method described in claim 51, further including the step of: 
applying at least one verification test to the waterfall payment tax 

computations if the Approval-Monthly action is selected. 

53. The method described in claim 51, if the Approval- Quarterly action is 
selected, further including the steps of: combining the monthly waterfall payment 
tax data for the respective securitizations; 

applying at least one verification test to the combined data; and 
upon successful verification of the tax computations, changing the 
workflow status of the securitization to the Mail Reports queue and Ready status. 

54. The method described in claim 51, if the Approval-Annual action is 
selected, further including the steps of: 
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combining the quarterly tax data for the respective securitizations; 
applying at least one verification test to the combined data; and 
upon successful verification of the tax computations, changing the 
workflow status of the securitization to the Mail Reports queue and Ready status. 

55. The method described in claim 51, wherein, for a securitization in the 
Tax Approval queue, and the Ready milestone, the actions which the user is 
permitted to initiate further include: 

a Deny action; and 
a Tax Reports action. 

56. The method described in claim 55, further including the step of 
changing the workflow status of the securitization to a predetermined queue and 
milestone based on the structure of the specific securitization if the Deny action is 
selected. 

57. The method described in claim 55, if the Tax Reports action is 
selected, further including the steps of: 

making a list of tax reports accessible to the user; 
permitting the user to select of one or more reports; and 
activating a tax processing software module to generate the selected 

reports. 

58. The method described in claim 55, wherein, for a securitization in the 
Tax Reports queue, the actions which the user is permitted to initiate include: 

a Mail action; and 
a Tax Reports. 
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59. The method described in claim 58, if the Mail action is selected; 
further including the steps of: 

activating the tax processing software module to print quarterly and 
annual tax reports previously generated; 

identifying the next tax processing cycle; and 

changing the workflow status to the Ready for Tax Processing queue 
and Ready status for the identified period. 

60. The method described in claim 58, if the Tax Reports action is 
selected; further including the steps of: 

permitting tax reports to be selected by the user for generation; and 
generating the selected reports. 

61. The method described in claim 46, in which the milestones associated 
with the Ready for Tax Processing queue include Ready and Denied. 

62. The method described in claim 46, in which the milestones associated 
with the Tax Approvals queue include Ready and Denied. 

63. The method described in claim 46, in which at least a Ready milestone 
is associated with the Tax Reports queue. 

64. The method described in claim 1, further including the steps of: 
generating a selection screen having a plurality of active elements thereon; and 

permitting a user may initiate functions by selection of the active 

elements. 
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65. The method described in claim 64, wherein the functions which the 
user is permitted to initiate include one or more of: 

invoking an active deals display; 

viewing and changing index data used for waterfall payment 

calculations; 

viewing and changing details of the deal structures for the 
securitizations; 

viewing and changing information concerning those to whom 
responsibility may be assigned for particular securitizations; 

viewing and changing information concerning particular assignments; 

viewing and changing information concerning other individuals and 
entities interested in the securitizations or having information relevant thereto; 

viewing and changing information related to database structure; 

setting up and performing data verifications; 

viewing historical data concerning the securitizations; and 

establishing and updating security levels for access to information by 

users. 

66. The method described in claim 1, wherein the step of recording set up 
information includes: 

allowing a user to select pertinent information concerning a particular 
securitization for entry in fields on a plurality of data entry screens from lists stored 
in at least one database record; 

automatically filling in data in additional fields based on a selection 
made for at least one other field; and 
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allowing the user to create records for new information not contained 
in an existing database record by entering data in the fields of at least one data entry 
screen for that record. 

67. The method described in claim 66, wherein the step of recording set 
up information further includes permitting the user to edit existing database records 
by entering new information in the fields of at least one data entry screen for that 
record. 

68. The method described in claim 66, further including the step of 
allowing the user to make selections for at least some of the fields in a data entry 
screen from drop-down lists created from stored database records. 

69. The method described in claim 68, further including the step of 
determining the content of at least one of the drop-down lists as a function of the 
data selection made for another field. 

70. The method described in claim 68, further including the step of 
scrolling at least some of the drop-down lists on the basis of partial entries in text 
boxes for the lists. 

71. The method described in claim 1, wherein the step of recording set up 
information includes: 

allowing a user to access and enter data into the fields of a series of data 
input screens, each screen providing for entry of a particular type of data related to 
the particular securitization; and storing the data entered by the user in the database 
in response to a save command from the user. 
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72. The method described in claim 71, further including the step of 
permitting the user to access specific data entry screens by selecting tabs appearing 
on all of the screens in the series. 

73. The method described in claim 71, further including the step of 
displaying tables in at least some of the data input screens, the tables having a 
plurality of rows, each row representing a data base record and a plurality of 
columns, each column row representing the fields of the displayed records. 

74. The method described in claim 73, further including the step of 
automatically filling at least some of the fields of a particular database record based 
on selection by the user of data for another field for that record from a list. 

75. The method described in claim 71, further including the step of 
permitting the user access to a Setup data screen, an Output data screen, a Contacts 
data screen, a Steps data screen, a Quality Control data screen, an Inputs data screen 
and a Header/Footer data screen. 

76. The method described in claim 75, further including the step of 
permitting the user to enter data in fields of the Setup data screens identifying a 
particular securitization, and at least the basic functions to be performed in 
managing the particular securitization. 

77. The method described in claim 76, further including the step of 
permitting the user to enter data in fields, the Setup data entry screens identifying 
the frequency with which the basic functions are to be performed from a list of 
possible frequencies. 
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78. The method described in claim 75, further including the step of 
permitting the user to enter data in fields of the Output data entry screens which 
specify the distribution media, the subject matter, the format, the release date, 
recipient information and the title of each report to be created for a particular 
securitization. 

79. The method described in claim 75, further including the step of 
permitting the user to enter data in fields of the Contacts data entry screens from 
drop-down lists which exclude employees of the trustee. 

80. The method described in claim 75, wherein the workflow status of the 
securitizations is recorded in terms of basic functions to be performed, processing 
queues for each basic function and progress milestones for each queue, and further 
including the steps of: 

permitting a user to identify a particular securitization and a basic 
function on the Steps data entry screen; 

displaying a table in the Steps data input screens, the table having a 
plurality of rows, each representing a data base record for a specific queue and a 
plurality of columns, each representing the fields of the displayed records. 

81. The method described in claim 80, wherein the fields for each queue 
record include at least a queue identification field, a field identifying the individual 
responsible for performance of actions associated with the queue and a field 
specifying the day of the month on which the action is to be taken. 

82. The method described in claim 81, further including the step of 
permitting selection of the entry for the queue identification field from a drop-down 
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list populated from a database record in accordance with a basic function selected by 
the user. 

83. The method described in claim 82, further including the step of 
populating the queue identification drop-down list in a predetermined 

order representing the expected processing order for the selected basic function. 

84. The method described in claim 82, wherein the step of permitting 
queue selection from the queue identification drop-down list includes permitting 
concurrent selection of more than one item from the list. 

85. The method described in claim 81, further including the step of 
permitting selection of a Deny field for each queue record which specifies a 
workflow path change in case data is disapproved at a particular queue. 

86. The method described in claim 85, wherein the workflow path change 
is specified by flagging the Deny field, and wherein a data disapproval in a queue for 
which the Deny field has been flagged returns the status of the securitization to the 
nearest queue above in the processing order for which the Deny field has also been 
flagged, except that if the disapproval takes place in a queue for which the Deny 
field has been flagged, the status is returned to the immediately previous queue, 
irrespective of flagging of the Deny field. 

87. The method described in claim 75, further including the steps of: 
displaying a drop-down list of predefined data verification tests in the 

Quality Control data entry screens; 
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displaying tables in the Quality Control data entry screens, the table 
having a plurality of rows, each representing a data base record concerning use of a 
data verification test; and 

permitting a user to select at least one verification test from the drop- 
down list, and to specify a queue and milestone at which the selected verification 
test is to be performed. 

88. The method described in claim 87, wherein the step of permitting 
verification test selection from the verification identification drop-down list includes 
permitting concurrent selection of more than one item from the list. 

89. The method described in claim 75, further including the steps of: 
permitting a user to identify a particular securitization and a basic 

function on the Steps data entry screen; 

displaying a table in the Steps data input screens, the table having a 
plurality of rows, each representing a data base record for a specific queue and a 
plurality of columns, each representing the fields of the displayed records. 

90. The method described in claim 75, wherein the aggregated asset level 
data is transmitted in the form of at least one database record having a first 
structure, and further including the step of: 

permitting a user to remap fields of the first database structure in the 
Inputs data entry screen to correspond to fields of a second database structure used 
in performing the waterfall payment calculations. 

91. The method described in claim 90, further including the steps of: 
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displaying two tables in side-by-side relation in the Inputs data entry 
screen, the tables having a plurality of aligned rows, with the rows of the first table 
permitting selection of fields of the first data base structure, and the rows of the 
second table permitting selection of fields in the second database structure; and 

permitting the user to populate respective aligned rows of the two 
tables with data to identify corresponding fields in the two database structures for 
the particular securitization. 

92. The method described in claim 91, wherein the data for the fields are 
selected from drop-down lists of the fields in the respective database structures. 

93. The method described in claim 92, further including the steps of: 
permitting the user to select a previously created mapping as a template 

for a new mapping; and 

populating the rows of the two tables to reflect the previously created 

mapping. 

94. The method described in claim 90, further including the step of: 
permitting the user to select a previously created mapping as a template 

for a new mapping. 

95. The method described in claim 75, further including the steps of: 
permitting the user to identify a particular securitization in the 

Header/Footer data entry screen; and 

permitting the user to specify in the Header/Footer data entry screen, 
the text and page location of headers and footers to be used in periodic reports for 
the specified securitization. 
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96. he method described in claim 74, further including the step of 
permitting a user to enter data in an index rate data entry screen which identifies a 
particular securitization, and specifies an index and the source thereof for use in the 
waterfall calculations for the particular securitization. 

97. The method described in claim 96, further including the step of 
permitting a user to enter dates in the index rate data entry screen for which values 
of the specified index are to be determined in connection with the particular 
securitization. 

98. The method described in claim 74, further including the step of 
permitting a user to enter data in a global staff/contact data entry screen concerning 
changes which affect a plurality of securitizations. 

99. The method described in claim 98, further including the steps of: 
permitting the user to formulate a database query on the global 

staff/contact data entry screen; and 

providing a report thereon based on variables included in the query. 

100. The method described in claim 99, further including the steps of: 
permitting the user to formulate the query in terms of the value of at 

least one variable including queue type, previous staff person or contact, and new 
staff person or contact; and 

providing a report which lists all securitizations and queues 
corresponding to the variable values included in the query. 

101. The method described in claim 74, further including the step of: 
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permitting a user to identify on a privilege level data entry screen, roles 
of individuals having responsibility for performing the trustee's duties, and to specify 
levels of data access for data viewing and modification for the established queues and 
milestones. 

102. The method described in claim 1, further including the steps of: 
permitting the user to formulate a database query on the active deals 

display screen; and 

providing a report thereon based on variables included in the query. 

103. The method described in claim 102, further including the steps of: 
permitting the user to formulate the query in terms of the value of at 

least one variable including user name, queue type, securitization name, basic 
function, and need for current activity; 

providing a report which lists at least the securitizations, basic functions 
and workflow status for listed securitizations corresponding to the variable values 
included in the query. 

104. The method described in claim 1, in which the active deals screen is 
provided with a table thereon, the table including rows each of which contains 
workflow status information concerning a particular securitization, and further 
including the steps of: 

permitting a user to select a specific securitization; and thereafter 
presenting the user a pop-up selection list from which specific actions applicable to 
the workflow status of the selected securitization may be initiated. 
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105. The method described in claim 104, wherein at least some actions 
available in some of the pop-up selection lists require supporting documentation, 
and further including the steps of: 

presenting the user with a data entry screen for providing the required 
documentation; and 

carrying out the selected action after the supporting documentation has 
been provided. 

106. The method described in claim 1, further including the step of 
permitting a user to manually enter information required for waterfall payment and 
tax processing which is not provided as part of the aggregated asset level data. 

107. The method described in claim 1, further including the steps of: 
permitting a user to set up data verification tests as part of the deal 

setup information, and to specify queues and milestones at which the tests are to be 
applied; and 

prompting the user on the active deals screen when predefined 
verification tests are to be performed. 

108. The method described in claim 107, further including the step of: 
permitting the user to customize pre-existing verification tests for reuse. 

109. The method described in claim 108, wherein the step of setting up a 
verification includes the steps of: 

selecting the variable to be used; 

defining specific parameters needed for a particular securitization; 
programming the necessary calculations; 
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assigning importance to an abnormal result; and 
assigning the verification to a basic function and queue. 

110. The method described in claim 109, further including the steps of: 
providing at least one data entry screen for use in formulating 

verifications; and 

providing drop-down selection lists for selecting pre-existing 
verifications for modification, for specifying the basic function and queue at which 
the verification is to be performed, for selecting variables, parameters and values 
thereof, and for specifying the workflow consequences of an abnormal result. 

111. The method described in claim 110, further including the step of: 
providing a text box for use in creating a formula to be performed as 

the verification. 

112. The method described in claim 110, further including the step of: 
permitting the creation of the formula using words and mathematical 

operators. 

113. A computerized method of workflow management for concurrently 
handling a plurality of complex multiple step projects, the method comprising the 
following steps, all under control of workflow management software: 

creating in a database, a project setup record which uniquely 
characterizes each project; 

recording workflow status information for the projects in a database; 

providing access for a user to a computer generated workflow status 
display generated at least in part from the project setup information records and the 
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workflow status information, which display permits access to workflow status for 
selected projects, provides prompts for the user as to work which is to be done with 
respect thereto, and permits the user to initiate actions; and 

automatically updating the workflow status record in the database 
whenever there is a change in the status of a project resulting from action initiated 
by the user. 

114. The method described in claim 113 further including the steps of: 
automatically performing required tasks according to the information 

stored in the project setup record for the project; and 

automatically updating the workflow status record in the database 
whenever there is a change in the status of a project resulting from automatic 
performance of required tasks. 

115. The method described in claim 113, wherein the step of recording 
workflow status information includes the step of entering information in database 
fields which identify basic functions involved in executing the project, workflow 
queues associated with the basic functions and milestones associated with the 
workflow queues. 

116. The method described in claim 95, wherein the information entered in 
the fields is derived, at least in part, from pre-stored lists. 

117. The method described in claim 94 further including the step of 
creating the project setup records at least in part from lists of pre-stored 
information. 
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118. The method described in claim 113, further including the steps of: 
receiving information required for execution of the projects 

electronically from a source external to the workflow management software; 

electronically transmitting information for performance of data 
processing tasks to at least one module external to the workflow management 
software; and 

electronically receiving data from the external module representing the 
result of the data processing tasks performed. 

119. The method described in claim 118, wherein the information from the 
external source is in the form of database records, and further including the step of 
providing an interface which remaps the database structure of the information for 
compatibility with the workflow management software. 

120. The method described in claim 113, further including the step of 
electronically disseminating reports and other data compilations concerning the 
execution of the project. 

121. The method described in claim 113, in which the status information is 
displayed in terms of basic functions associated with management of the project, 
workflow queues associated with the basic functions and milestones associated with 
the workflow queues. 

122. The method described in claim 113, further including the steps of: 
prompting the user to review data at predetermined stages of the 

projects; 

permitting the user to take action based on the review; and 
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changing the workflow status of the projects in accordance with the 
actions taken. 

123. The method described in claim 122, further including the step of 
requiring entry of supporting information by the user on a data entry screen before 
changing the workflow status of a project, for at least some actions taken by the 
user; and 

storing the supporting information in a database record. 

124. The method described in claim 113, wherein the workflow status 
display presents a list of projects, and wherein the method further includes the step 
of providing an actions list containing the actions available to the user as a pop-up 
selection screen on the active deals display which appears when a listed project is 
selected. 

125. The method described in claim 113, further including the step of 
generating a selection screen having a plurality of active elements thereon from 
which a user may initiate tasks by selection of the active elements. 

126. The method described in claim 113, wherein the step of creating the 
project setup record includes: 

allowing a user to select pertinent information concerning a particular 
project from lists stored in at least one database record for entry in fields on a 
plurality of data entry screens; 

automatically filling in data in additional fields based on a selection 
made for another field; and 
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allowing the user to create records for new information not contained 
in an existing database record by entering data in the fields of at least one data entry 
screen. 

127. The method described in claim 126, wherein the step of creating the 
project setup record further includes permitting the user to edit existing database 
records by entering new information in the fields of at least one data entry screen. 

128. The method described in claim 127, further including the step of 
allowing the user to make selections for at least some of the fields in a data entry 
screen from drop-down lists created from stored database records. 

129. The method described in claim 128, further including the step of 
determining the content of at least one of the lists as a function of a data selection 
made for another field. 

130. The method described in claim 129, further including the step of 
scrolling at least some of the lists on the basis of partial entries in text boxes for the 
lists. 

131. The method described in claim 113, wherein the step of creating the 
project set up record includes the steps of: 

allowing a user to access and enter data into the fields of a series of data 
input screens, each screen providing for entry of a particular type of data related to 
the project; and 

storing the data entered by the user in the database in response to a 
save command. 
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132. The method described in claim 131, further including the step of 
permitting the user to access specific data entry screens by selecting tabs appearing 
on all of the screens in the series. 

133. The method described in claim 113, wherein the step of creating the 
project setup record further includes the step of permitting the user to specify 
workflow path changes in accordance with predetermined contingencies. 

134. The method described in claim 115, further including the steps of: 
permitting the user to access a list of predefined data verification tests; 

and 

permitting a user to select at least one verification test from the list; and 
permitting the user to specify a queue and milestone at which the 
selected verification test is to be performed. 

135. The method described in claim 113, wherein the step of permitting 
verification test selection includes permitting concurrent selection of more than one 
item from the list. 

136. The method described in claim 94, wherein the step of providing 
access to the workflow status display further includes the steps of: 

permitting the user to formulate a database query on the display screen 
from fields representing variables for the query; and 

providing a report thereon based on variables included in the query. 

137. The method described in claim 95, further including the step of: 
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permitting a user to specify roles of individuals having responsibility for 
executing the project, and to specify levels of data access for data viewing and 
modification for the recorded queues and milestones. 

138. The method described in claim 95, wherein the step of creating the 
project set up record includes: 

permitting a user to set up data verification tests as part of the deal 
setup information, and to specify queues and milestones at which the tests are to be 
applied. 

139. The method described in claim 138, further including the step of: 
permitting the user to customize pre-existing verification tests for reuse. 

140. The method described in claim 139, wherein the step of setting up a 
verification includes the steps of: 

selecting variable to be used; 

defining specific parameters for the test; 

programming necessary calculations; 

assigning importance to an abnormal result; and 

assigning the verification to a basic function and queue. 

141. The method described in claim 140, further including the steps of: 
providing at least one data entry screen for use in formulating 

verifications; and 

providing selection lists for specifying pre-existing verifications for 
modification, for specifying the basic function and queue at which the verification is 
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to be performed, for selecting variables, parameters and values thereof, and for 
specifying the workflow consequences of an abnormal result. 

142. The method described in claim 141, further including the step of: 
providing a text box for use in creating a formula to be performed as 

the verification. 

143. The method described in claim 141, further including the step of: 
permitting the creation of the formula using words and mathematical 

operators. 

144. A workflow management system for a trustee handling a plurality of 
securitizations comprising: 

an electronic deal setup database which stores deal setup information, 
including information related to the structure of the securitizations; 

a first data processing software module which receives asset level data 
transmitted by at least one asset manager and aggregates the asset level data; 

a workflow management software module; 

an first interface which receives the aggregated asset level data from the 
first data processing software module, and transmits the data electronically to the 
workflow management software module; 

a computer display generated under control of the workflow 
management software module, which displays status information concerning a 
particular securitization, provides prompts to a user as to work which is to be done 
with respect thereto, and which includes at least one active element from which the 
user may initiate actions with respect to the work; 
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a second data processing software module which receives the 
aggregated asset level data, and responds to commands from the workflow 
management software module to perform computations related to payments due 
investors in the securitization; 

a second interface; and 

a third data processing software module which receives payment data 
produced by the second data processing software module through the second 
interface, and responds to commands from the workflow management software 
module to processes payments to the investors based on the payment data. 

145. The system described in claim 144, further including 

an electronic workflow status database which stores workflow status 
information for the securitizations. 

146. The system described in claim 144, wherein the the computer display is 
based at least in part on recorded deal setup information in the electronic database. 

147. The system described in claim 145, wherein the the computer display is 
based at least in part on workflow status information recorded in the workflow 
status database. 

148. The system described in claim 145, wherein the workflow management 
software module is operative to update the workflow status database in response to 
actions initiated by users, and work completed. 



119066 v1;2JV#01!.DOC 



43 



Application No.: 09/631,810 



Docket No.: J2167.0221 



149. The system described in claim 144, wherein the electronic deal setup 
database stores information related to the performance of the trustee's duties in 
connection the securitizations. 

150. The system described in claim 144, further including a data handling 
device responsive to data and commands from the workflow management software 
module the data handling device being operative to electronically disseminate 
reports and other data compilations upon completion of the payment processing. 

151. The system described in claim 144, wherein the aggregated asset level 
data is in database form, and wherein the first interface maps the database structure 
of the aggregated asset level data for compatibility with the second data processing 
software module. 

152. The system described in claim 151, wherein the payment data 
produced by the second data processing software module is in database form, and 
wherein the second interface maps the database structure of the payment data for 
compatibility with the third data processing software module. 

153. A workflow management system for handling a plurality of complex 
multiple step projects comprising: 

an electronic workflow management database which stores project 
setup information, including organizational information concerning the projects, 
and the sequence of workflow required to execute the project; 

a first data processing software module which receives raw data 
required to execute the project from at least one outside source, and processes the 
raw data; 
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a workflow management software module; 

a first interface which receives the processed raw data from the first data 
processing software module, and transmits the data electronically to the workflow 
management software module; 

a computer display generated by the workflow management software 
module, which displays workflow status information concerning the projects, 
provides prompts to a user as to work which is to be done with respect thereto, and 
which includes at least one active element from which the user may initiate actions 
with respect to the work; 

a second data processing software module which receives the processed 
raw data, and responds to commands from the workflow management software 
module to perform computations using the processed raw data; 

a second interface; and 

a third data processing software module which receives data through 
the second interface, and responds to commands from the workflow management 
software module to processes the received data. 

154. The system described in claim 153, further including a data handling 
device responsive to data and commands from the workflow management software 
module, the data handling device being operative to electronically disseminate 
reports and other data compilations. 

155. The system described in claim 153, wherein the processed raw data is 
in database form, and wherein the first interface maps the database structure of the 
processed raw data for compatibility with the second data processing software 
module. 
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156. The system described in claim 155, wherein the data produced by the 
second data processing software module is in database form, and wherein the second 
interface maps the database structure of the data provided the second data 
processing software module for compatibility with the third data processing software 
module. 

157. The system described in claim 155, wherein the the computer display is 
based at least in part on recorded setup information in the electronic database. 

158. The system described in claim 153, wherein the workflow management 
software module is operative to update the workflow status database in response to 
actions initiated by users, and work completed. 
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